1. Field of the Invention
The present invention relates generally to image/video display and processing systems, and in particular, to a method, apparatus, and article of manufacture for tracking rendering information using a database and viewing such information once rendering is complete.
2. Description of the Related Art
A clip is a sequence of images or frames loaded from an external device such as a VTR (video tape recorder), stored in digital format, and displayed in a clip library and on a desktop. Clips may be edited, combined, processed, and recorded to/on external devices. The production of a final clip sequence is typically performed by a “render-farm,” a large number of dedicated computers that are used exclusively for image/clip rendering. However, while the individual dedicated computers may determine or track relevant information during the rendering process, such information is merely maintained on a per-rendering session basis and a log of the information is not retained. Further, the information cannot be linked to the design stage of clip processing nor can the information be used to calculate costs or evaluate time and financial information that is based on the rendering. Such problems may be understood with an explanation or prior art clip processing and rendering.
Post production of sequences for film and video is an extremely complex and expensive undertaking. Each clip may have dozens of separate elements/operations that need to be combined/composited, each individual element requiring significant effort on the part of a digital artist. For example, to composite a moving car onto a new background may require a mask for the car be cut and perfected for every frame of the sequence.
Professional compositing software helps digital artists and managers visualize the process of clip development/design by building a “dependency graph” of elements and effects for each sequence. In such software, operators, tasks, or modules/functions perform a variety of functions with respect to a clip or source. For example, a module may perform compositing, painting, color correction, degraining, blurring, etc. A dependency graph of such software may also be referred to as a process tree or a schematic view of a process tree. Such a tree illustrates the elements and effects needed to complete a sequence of functions and identifies the hierarchy that shows the relationship and dependencies between elements. Accordingly, as the end-user interacts with media and tools in a schematic view, the system constructs a graph representing the activity and the relationships between the media and tools invoked upon them. The purpose of the dependency graph is to manage and maintain the relationships between the nodes representing the media and the tools.
FIG. 1 illustrates a process tree in a schematic view. A schematic view 100 uses node(s) 102-104 to represent all of the operators in a workspace performed on one or more clips 106-110, and line(s) (edges) 112-118 between nodes clips 106-110 and nodes 102-104 to indicate the flow of image data between the operators. The output of one node 102 is the source for the next node 104. As a result clip 104 or other branch (e.g., paint or color correction projects 102) is created, the process tree indicating the flow of data through the nodes 102-104 is built automatically. As illustrated in FIG. 1, various source nodes in the form of clips 106-110 are utilized. As illustrated, front clip 106, back clip 108, and matte clip 110 may be utilized by color correction node 102. The color correction node 102 performs an operation (i.e., a color correction to the clips 106-110) on the clips 106-110 to produce a result/output 104.
As used herein, an operator (e.g., color correction operator 102) is the most common node. Alternative nodes may be used to connect two nodes. The process tree (such as the process tree illustrated in FIG. 1) can be used to manage operators and nodes. For example, users may add operators (e.g., a paint operation) to a branch, change the process order of operators 102-104, and navigate easily between operator controls. Further, if an operator is added to a layer in a schematic view 100, the operator will appear as a node (e.g., the color correct node 102). The same operator node may also appear in other workspace environments (e.g., a workspace panel). Further, in the schematic view, particular operators may be turned on/off as desired simply by clicking on the icon for that operator.
Thus, as described above, the dependency graph is the record of end-user activity in the creative application. The dependency graph is constructed by the system dynamically, consists of various nodes and connections, and is represented in the user interface as the schematic view 100. As the end-user manipulates media by editing, applying tools, etc., the creative application constructs a dependency graph reflecting the structure of the composition. For example, when the end-user drops a keyer into the schematic 100, the system creates an instance of a tool node for the keyer in the dependency graph 100.
Thus, the dependency graph consists of tool nodes, link nodes, and occasionally, group nodes. Tool nodes represent the invocation of a tool and its parameters. Link nodes connect the graph 100 to the published result of another composition and group nodes can be created by an end-user to arrange nodes together in the schematic 100 for visual clarity.
While the assembly and sequencing of clips and clip elements during the design phase is usually performed by artists on individual workstations, the production of the final clip sequence is typically done by a “render-farm,” a (large) number of dedicated computers (that may be geographically distributed across a network) that are used exclusively for image/clip rendering.
The rendering that is farmed out to these workstations is managed by special software (referred to as rendering management software) that monitors the status of individual machines and manages parsing out individual render tasks as machines become idle. However, the prior art fails to provide a mechanism to tie or link information generated by the rendering-management software (e.g., length of time taken for rendering, which machines were used, how much storage was consumed, etc.) with information generated in the design phase (e.g., how long each design element took to produce, etc.).
Accordingly, it is impossible in the prior art for post-production companies to obtain or maintain knowledge of information such as whether a job was profitable, which compositing techniques were/are efficient (for design and/or production), the cost for individual clip elements, the number of different variations of a given sequence that were created, which artist worked on a particular shot/project, etc. Understanding the financial impact of various design decisions is often critical to the viability of such post-production companies. However, the prior art fails to provide an efficient mechanism for tracking, maintaining, and viewing such information.
In view of the above, what is needed is a mechanism to effectively and efficiently obtain and view creative and non-creative aspects of clip processing/rendering.